Pooling rewards associated with accounts

ABSTRACT

The present invention is directed to a method for linking accounts corresponding to different products together to create a group so that group processing can be performed at the group level while independent processing of the accounts is performed at the account level. The method links the accounts into a group by linking a financial record for each account to group master data for the group. The group master data includes information about the group, including group control settings, aggregate data, and a group identifier. A group typically includes a key account and one or more dependent accounts. The relationship between a dependent account and the group is specified by a dependent strategy. A dependent strategy specifies group level processing options for the account. The relationships between the accounts and the group are flexible to accommodate changes in the status of the group cardholders. Alternative embodiments will be apparent to those skilled in the art to which the present invention pertains without departing from its spirit and scope. Accordingly, the scope of the present invention is described by the appended claims and is supported by the foregoing description.

CROSS-REFERENCES TO RELATED APPLICATIONS

[0001] This U.S. patent application is a continuation of U.S. patentapplication Ser. No. 09/298,417 entitled “Methods for Processing a Groupof Accounts Corresponding to Different Products” and filed on Apr. 23,1999. The aforementioned patent application is commonly assigned withthe present application to First Data Corporation.

BACKGROUND OF THE INVENTION

[0002] This invention relates in general to a method for processingaccounts corresponding to different products that are members of agroup, and more particularly to a method for processing a group ofaccounts that supports group level processing at the group level whileretaining independent processing of the accounts at the account level.

[0003] Many individuals hold more than one credit card. Additionally, anindividual may hold the liable relationship for more than one creditcard held by another individual or individuals. There are several typesof credit card products available. Some cards are private label cardsthat can only be used in a particular store or business, such as adepartment store card or a specialty chain store card. Other cards aregeneral use cards that can be used in a variety of stores or businesses,such as a VISA™, MASTERCARD™, AMERICAN EXPRESS™, DINER'S CLUB™ orDISCOVER™ card.

[0004] Cards held by an individual often include a variety of thesedifferent products and versions of these products. Different versions ofa product are offered to address different market interests and needs.For example, a VISA™ card could be a classic card, a gold card, or aco-branded card. Issuers often encourage their existing cardholders tocarry more than one of their products to increase the share of thatconsumer's activity for their products.

[0005] A consumer can be encouraged to hold multiple products and/orcards for any of a number of reasons. The number and type of cards heldby an individual are influenced by many factors, including interestrate, reward program and merchant acceptance. The activity on thevarious accounts held by an individual may vary due to the type ofexpenditure or the person making the purchase.

[0006] Different cards can be used by a single consumer to managedifferent types of expenditures. For example, one card can be used foreveryday household expenditures, such as groceries and gasoline, anothercard can be used for major household expenditures, such as majorappliances or furniture, and yet another card can be used for vacationexpenditures.

[0007] Many credit card products offer a reward program to provide anincentive for a cardholder to use the card associated with the program.An individual often carries different cards to participate in a varietyof different reward programs. A typical reward program awards pointsbased upon the amount and/or type of purchases made with the card.Depending on the purchase, an individual may select the card with thegreatest reward opportunity associated with that particular purchase.

[0008] In addition to carrying multiple cards as an individual, anindividual can share ownership of credit products carried by othermembers of their family. For example, in a family including a mother, afather, a daughter and a son, each parent can hold a number of cards. Inaddition to the parents, the children can also hold cards. Some of thecards can be held individually and some can be held jointly. To helpmanage the family finances, it would be beneficial if information aboutall of the cards held by members of the family could be collected in asingle statement.

[0009] If the members of a family hold distinct accounts, the rewardpoints earned by the family members are generally divided amongdifferent reward programs and/or different accounts. An issuer may finda marketing advantage if the accounts could be pooled together, makingit easier for the members of the family to reach a point goal. Thus,there is a need for pooling reward points earned by differentindividuals using different accounts.

[0010] Depending upon the age and status of the children, the motherand/or the father is liable for any charges incurred by the son ordaughter. Typically, if a parent wants to provide a child with a creditcard, the parent has three options: 1) provide the child with anadditional card on an existing account, 2) provide the child with a cardon an account where the child is the primary user and the parent is theresponsible party, or 3) provide the child with a secured card byproviding collateral for the account.

[0011] Each of the current options has disadvantages. A disadvantage ofproviding the child with an additional card on an existing account isthat the child has access to the entire credit line of the account. Adisadvantage of providing the child with a card on an account where thechild is the primary user and the parent is the responsible party isthat the parent's access to credit may be reduced. If the parent alsohas another account, then the credit line given to the child is notavailable to the parent even if the child is not currently using itbecause the accounts are unrelated. A disadvantage of providing thechild with a secured card by providing collateral for the account isthat the collateral is committed to secure the account regardless of theamount of activity on the account. A secured account also may notinclude a process to report activity to the parent providing thecollateral. Thus, there is a need for additional options for anindividual to provide a child with a credit card. In particular, thereis a need for limiting a child's access to a shared credit line and forconsidering multiple accounts when calculating an individual's availablecredit.

[0012] As a result of these market realities, issuers are faced with achallenge to manage an individual's whole relationship with them whileoffering the flexibility consumers desire in their product options.Issuers want a complete answer to manage an individual as a relationshipand to maintain control and marketing data at the lowest possible level.The lowest level being a single person using a single product version.Currently, several solutions exist which answer varying components ofthe problem. Additional names, commercial card functions, data stores,plastic/account separation, and other off line processing all provideonly partial solutions.

[0013] Some credit card issuers facilitate group processing bymaintaining additional names on an account. This basic functionalityidentifies multiple cardholders as authorized users on the samefinancial record. In addition to the issues of shared credit linesdiscussed above, this functionality requires that all cardholders sharethe same credit product and product version. This option also providesalmost no functionality at the cardholder level. All activity ismaintained and managed at the account level which merges the individualcardholders together. This limits the issuer's ability to completemarketing analysis on individual group members.

[0014] As an extension of the additional names functionality, someprocessing systems allow the cards which correspond to the additionalnames to have distinct card numbers. Financial calculations on theseaccounts are still done at the account level, but the individualtransaction activity can be tracked back to a particular cardholder.This functionality does not solve the shared credit issues or theability to make other processing decisions at the card level.

[0015] Some credit card issuers provide commercial card accounts. Acommercial card account is a single financial account that is associatedwith multiple cards. All of the, cards are the same type and version ofa product, e.g. a standard VISA™ card. Each of the cards can have adifferent card number. The different card numbers can be used to listthe transactions by cardholder on the statement. A single groupstatement is sent to the financially responsible party, usually thecompany.

[0016] In most applications of commercial card functionality, the subaccounts are actually contained on a distinct financial record, but therecord is only a shell of information. The true financial activity istransferred to the group or lead account. This functionality does notaccommodate different types or versions of credit card products.Although several authorization options exist, the restrictions are basedon monthly spending limits rather than a true available credit. This isbecause outstanding balances are not monitored at the individual cardlevel. Commercial cards also do not accommodate different types ofcardholder relationships to the group. An employee card is either paidfor by the employee or by the company. A family or household scenariorequires a greater variation of communication and liability options. Afamily scenario also requires that an account can become independent ofthe group or other existing accounts can be added to the group.

[0017] If a child can qualify for a credit card individually, then thechild can be the responsible party or a jointly liable party for theaccount. For example, a child can qualify for a credit card individuallyif the child is a college or university student. Even if a child canqualify for a credit card individually, an individual, such as a parent,may want to monitor the activity of the account to help the child managethe child's credit. Thus, there is a need for providing courtesy copiesof account activity to an individual, such as a parent.

[0018] An individual's credit needs change over time because thefinancial ability of the individual, as well as the financial maturityof the individual change. For example, at one point, a child may not beable to qualify individually for a credit card and may need anindividual, such as a parent to be the financially responsible party forthe card. At another point, the child may be able to qualifyindividually for a credit card, but may benefit from some assistance orsupervision from a parent. At yet another point, the child may be ableto qualify individually for a credit card and to manage the accountwithout assistance. Often times an individual uses different credit cardaccounts to meet the individual's different needs. However, it would besimpler if a single credit card account could adapt to meet thedifferent credit needs of an individual by accommodating different typesof cardholder relationships.

[0019] Some issuers manage distinct accounts at the lowest level thendepend on outside data stores to integrate group data into themanagement of the accounts. Outside data stores are data query systemswhich are maintained outside the core processing system. They are oftentied into operations centers for informational look up processing. Thedata stores are maintained by loading data from the core processingsystem. Issuers populate data stores and load “keys” onto accountrecords to link accounts. These links allow customer service personneland collectors to recognize individuals who hold multiple accounts. Datarelated to the various accounts can be displayed for use in manualservice activity. This type of functionality is not integrated intoautomatic processing functions. In many cases, the operator would haveto take further action to define the relationship the linked accountshave to one another. The card may or may not be held by the sameindividual or the accounts may not have the same jointly liablerelationship to a second person. Thus, there is a need to integrategroup processing into the automatic functions of a processing system toavoid the expense and issues of manual intervention.

[0020] Some issuers use these same off line data stores to processscoring engines. The scoring engines allow numeric values to be assignedto accounts which could allow the existence of other accounts held bythe same individual to impact the processing of the first account. Thisprocess can be automatic but it assumes a generally static relationship.Typically, this type of functionality does not provide an easy audittrail to find the accounts which were included in the scoring activity.In addition, the processing activity remains at the account level ratherthan the group level. Credit lines, statements, and correspondence arenot managed at the group level.

[0021] Some issuers attempt to manage some of these issues bydistinguishing distinct balances on a single financial record. Thisprocessing is referred to as transaction processing. Transactionprocessing allows a sub record within the financial processing of anaccount. One balance can apply to one set of pricing controls, but notfor distinct authorizations, ownership, or delinquency management. Thepayoff of these balances can be controlled, but the delinquency is thedelinquency of the account as a whole. This functionality also does notallow management of distinct owners.

[0022] Some issuers address these challenges with off line or manualprocesses. For example, a jointly held account for a college age childmay carry the child's mailing address and both the child and theparent's name. However, if the account becomes delinquent, off linefiles are used to find the parent's address and manual collectionefforts are made toward the parent. In some cases, this might be thefirst notice to the parent of the delinquent state of the account.

[0023] Accordingly, there is a need in the art for a method for linkingone or more accounts together to form a group to support integratedgroup level processing while maintaining individual processing to theaccounts. Preferably, the accounts of the group can span multipleproducts and the relationship of each account to the group is flexibleand independent of the other accounts in the group.

BRIEF SUMMARY OF THE INVENTION

[0024] The present invention meets the needs described above byproviding a method for linking accounts corresponding to differentproducts together to create a group so that group processing can beperformed at the group level while independent processing of theaccounts is performed at the account level. A group includes a number ofaccounts that correspond to a single issuer. The accounts can spanmultiple products so that an account corresponding to a VISA™ productcan be in the same group as an account corresponding to a MASTERCARD™product. Each group has a primary owner. A primary owner is the intendedrecipient of group correspondence and the primarily liable party of anygroup liability. Generally, the primary owner corresponds to acardholder for a key account. However, a key account is not required.All non-key accounts in the group are dependent accounts. A dependentaccount may or may not be included in the group liability.

[0025] Linking the accounts into a group is accomplished by linking thefinancial record that corresponds to each account to the group masterdata for the group. A key financial record corresponds to the primaryowner and the key account (if any). A dependent financial recordcorresponds to each of the dependent accounts. Dependent accountsinclude all non key group members regardless of the relationship theaccount has to the group. The group master data includes informationabout the group, including control settings, aggregate data, and a groupidentifier. The membership to the group is maintained within the groupdata and on each member financial record.

[0026] The relationship between the financial record and the groupdefines the processing impacts of membership to the group on theindividual financial record. The relationship of the key account to thegroup is that of primary owner. A majority of the processing impacts ofthat relationship are typically predefined by the card processing andservice provider. The relationship of a dependent account to the groupis defined by a set of processing options. These processing options aredefined as a dependent strategy. A dependent strategy specifies theimpact of group level processing on the processing of the dependentaccount. Typically, the dependent strategy includes parameters thatdefine how and when group membership impacts transaction authorizations,group payment applications, as well as whether payment for the accountbalance is due from the primary owner or from the dependent cardholder.In addition, the dependent strategy includes options for statementgeneration, cardholder communications, and reward pooling.

[0027] The relationship between each account in the group is flexibleand can be modified. A group can contain some dependent accounts whichprocess as completely subordinate accounts with no direct communicationto the dependent cardholder and other dependent accounts which processas secondary or joint owners of the group with full disclosure of allgroup activity. Each defined dependent strategy can be used to definethe relationship of any number of accounts to any number of groups.Also, each group can include dependent accounts with relationshipsdefined by any number of different strategies. Additionally, an existingrelationship between a given dependent account and a group can bechanged from one strategy to another strategy. The ability to modify thedependent strategy allows the account processing to change as thecardholder's situation changes. Changing the dependent strategy of oneof the dependent accounts does not impact the dependent strategies ofthe other dependent accounts.

[0028] The relationship of the primary owner can also be changed. A keyaccount can be modified to be a dependent account or removed completelyfrom the group. This action is allowed as long as a new primary owner orkey account is identified (if one is required). A dependent account canbe “matured” into a key account. To mature a dependent account into akey account, the relationship parameter for the dependent account ischanged from dependent to key and the relationship parameter for thecurrent key account is changed to dependent.

[0029] There are a number of ways that a group can be created. One wayto create a group is to create a number of new accounts and link the newaccounts together. Another way of creating a group is to link a numberof existing accounts together. The group data is automatically generatedwhen the first member of the group is identified. Once a group iscreated, additional accounts can be added to the group or existingaccounts can be removed from the group.

[0030] A dependent account can be added to the group or removed from thegroup without affecting the remaining accounts in the group. The abilityto add dependent accounts and delete dependent accounts allows the groupto change to accommodate changes in the relationships between theprimary owner and the dependent cardholders. For example, the dependentcardholder may be a minor child of the parent who is the primary owner.Initially, all disclosures and liability is held by the parent andtherefore communications are sent to the parent. Later the child maybecome a college student with joint liability for the account andresponsibility for the monthly payments. At this time the parent isreceiving courtesy disclosures. The processing for the child's accountcan change with the relationship by changing the dependent strategy.

[0031] To add a dependent account to a group, the dependent financialrecord for the dependent account is linked to the group master data. Thelink is stored in the group master data and on the dependent financialrecord. These two records are compared daily to ensure that no out ofsync condition has occurred. The history which accrued on an accountprior to joining a group will remain intact after it is linked into thegroup.

[0032] To remove a dependent account from the group, the dependentfinancial record for the dependent account is delinked from the groupmaster data. The history which accrued during the period that an accountwas a member of the group also remains intact when the account isdelinked. Removing a dependent account from a group may correspond to achange in family status. If an account is removed from a group, it canbe moved to an existing group, used to create a new group, or can bedesignated as an independent account that is not a member of a group.

[0033] If all the accounts associated with a group are removed from thegroup, then the group continues to exist for some pre defined period oftime even though the group does not have any members. The groupcontinues to exist so that audit history for the group can be maintainedfor the pre defined period of time.

[0034] Once a group is created it can be used to perform groupprocessing. Group processing typically includes authorizingtransactions, applying group payments, creating group statements,controlling cardholder communications, and administering reward programsfor the accounts in the group.

[0035] Group authorizations allow issuers to set a group credit line andmanage the group available credit across all participating groupmembers. All authorization controls and limits are calculated using thegroup credit line and available credit. Monetary activity from anyparticipating group member may increase or decrease the group availablecredit. The key account always participates in authorizations at thegroup level. The dependent accounts in the group participate in thegroup authorizations as an option. In one aspect of the invention, thedependent strategy includes three authorization options for a dependentaccount. One authorization option considers only the credit line andavailable credit of the group, a second option considers only the creditline and available credit of the dependent account, and a third optionconsiders the credit line and available credit of both the group and thedependent account. This function differs from the prior art in that theindividual available credit is calculated against maintained balances bymaintaining monetary history on the individual account. In the prior artapplications, the individual member does not have a maintained balanceover time. Monetary balances are transferred to an owner account and theindividual line is refreshed. In this type of application, theindividual is authorizing against a monthly spending limit rather than atrue credit line.

[0036] Group balances including minimum payments due (“MPD”) andoutstanding balances are calculated and stored in the group master data.These amounts are then reported to the primary owner. The key account isalways included in these calculations. The dependent accounts in a groupare included in the calculation as an option. In one aspect of theinvention, the dependent strategy defines the responsible party for thepayments on that account. One option requires the payment of thedependent account balance to be due from the primary owner, and a secondoption requires the payment of the dependent account balance to be duefrom the dependent cardholder.

[0037] Group processing includes the ability to process payments orcredits received at the group level. Once recognized as a group payment,the credit is allocated across all participating accounts in the group.An account participates in the allocation of credit depending on how itwas included in the group MPD and outstanding balance during the laststatement processing and the applicable group control settings.Alternatively, the payment may be allocated manually across the accountsin the group based on issuer policy or cardholder direction. In oneaspect of the invention, the allocation of a group payment is determinedby a combination of the group payment amount, the stored group balances,the stored individual balances which correspond to the group balances,and group control settings which determine which balances to use. Inthis aspect, percentages are used to determine the value of eachaccount's allocation. Payment is allocated to accounts based on thataccount's share of each type of group balance in the order that thebalances are defined by the group controls.

[0038] A group statement is created for the group and is sent to theprimary owner. The group statement includes information about theactivity of the key account (if any) and the activity of the dependentaccounts of the group. The amount of information that appears on thegroup statement about a dependent account is controlled by the dependentstrategy. Depending upon the dependent strategy, the group statementincludes details of the activity of the dependent account or a summaryof the activity of the dependent account. If the dependent strategyspecifies that payment for the dependent account is due from the group,then the strategy also specifies whether a courtesy statement is sent tothe dependent cardholder.

[0039] Group processing can impact the intended recipient and content ofother cardholder communications. In addition to statements, severalcommunications are typically generated for an account. If the accountgenerating the activity is a dependent account, the correspondence canbe redirected to the primary owner of the group. In one aspect of theinvention, a series of options on the dependent strategy define theaddressee or the intended recipient of an original communication, suchas a letter, a notice or a new plastic. The intended recipient can beeither the primary owner or the dependent cardholder. In the case ofletters and notices, the options also includes the ability to generate acourtesy copy of the communication for the party who did not receive theoriginal. If multiple letters are redirected to the primary owner, thoseletters can be merged into a single letter including the variablecontent from the various group member accounts.

[0040] Group processing also includes options for pooling and redeemingreward points. A parameter included in the definition of a particularreward program indicates whether the program supports reward pointpooling. If the program supports pooling, then any reward points forthat program which are earned by the key account (if any) are pooledinto a group pool. The primary owner is permitted to redeem group rewardpoints. The dependent strategy specifies whether reward points earned bya dependent account are pooled or are maintained at the account level.The dependent strategy also specifies whether the dependent accountcardholder can redeem group reward points. The group pool is independentof any member account. Accounts can be delinked from the group withoutimpacting the group accumulation.

[0041] Group non monetary transactions support group level processing byupdating multiple accounts within a group. A non-monetary transaction isa transaction that affects information for one or more accounts withinthe group, but does not affect the monetary information for the account.For example, a change in billing address is a non monetary transaction.A group non monetary transaction can be used to update all of theaccounts in the group while only requiring that the updated informationbe entered once. To update the accounts in a group with updated groupinformation, the accounts within the group are identified by theprocessing system using the group data. Once the financial records areidentified, the operator is given an option to update all or onlyselected records, and then the financial records are updated with theupdated information.

[0042] These and other objects, features, and advantages of the presentinvention may be more clearly understood and appreciated from a reviewof the following detailed description and by reference to the appendeddrawings and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0043]FIG. 1 is a block diagram illustrating an exemplary relationshipbetween a card processing and service provider, issuers and cardholders.

[0044]FIG. 2 is a block diagram illustrating an exemplary relationshipbetween a card processing and service provider, an issuer and thecardholders within a group in accordance with an embodiment of thepresent invention.

[0045]FIG. 3 is a block diagram illustrating the relationship between acard processing and service provider, issuers and the cardholders withina group in accordance with an embodiment of the present invention.

[0046]FIG. 4A is a block diagram illustrating the files included in thegroup master data in accordance with an embodiment of the presentinvention.

[0047]FIG. 4B is a block diagram illustrating group master data inaccordance with an embodiment of the present invention.

[0048]FIG. 5 is a flow diagram illustrating the steps for creating agroup using new accounts in accordance with an embodiment of the presentinvention.

[0049]FIG. 6 is a flow diagram illustrating the steps for creating agroup using existing accounts in accordance with an embodiment of thepresent invention.

[0050]FIG. 7A is a flow diagram illustrating the steps for adding adependent account to a group in accordance with an embodiment of thepresent invention.

[0051]FIG. 7B is a flow diagram illustrating the steps for authorizing atransaction in accordance with an embodiment of the present invention.

[0052]FIGS. 8A and 8B are flow diagrams illustrating the steps forapplying a payment in accordance with an embodiment of the presentinvention.

[0053]FIG. 9 is a flow diagram illustrating the steps for identifyingintended recipients of statement data and providing statement data inaccordance with an embodiment of the present invention.

[0054]FIG. 10 is a flow diagram illustrating the steps for redeeminggroup reward points in accordance with an embodiment of the presentinvention.

DETAILED DESCRIPTION OF THE INVENTION

[0055] The present invention is directed to a method for linkingaccounts corresponding to different products together to create a groupso that group processing can be performed at the group level whileindependent processing of the accounts is performed at the accountlevel. The accounts in a group can span multiple products. A typicalgroup includes a key account and one or more dependent accounts. Eachgroup has a primary owner. Generally the primary owner corresponds to acardholder for the key account.

[0056] Briefly described, the method links the accounts into a group bylinking a financial record for each account to group master data for thegroup. The group master data includes information about the group andthe group members, including group control settings, group aggregatedata, and a group identifier. The financial records include informationabout the corresponding account, a relationship parameter specifyingwhether the corresponding account is a key account or a dependentaccount, and if the financial record corresponds to a dependent account,a dependent strategy identifier.

[0057] The relationship between a dependent account and the group isspecified by a dependent strategy. A dependent strategy specifies groupprocessing options for the dependent account. The relationship between adependent account and the group can be changed by selecting a newdependent strategy.

[0058] The detailed description which follows is represented largely interms of processes and symbolic representations of operations by aconventional computer. The processes and operations performed by thecomputer, in both a stand alone environment and a distributed computingenvironment, include the manipulation of signals by a processor and themaintenance of these signals within a data set, such as a database and adata structure. Each of these data sets and data structures are residentin one or more memory storage devices. Basically, a data set is acollection of related information in separate elements that aremanipulated as a unit. A data structure is a structured organizationalscheme that encapsulates data in order to support data interpretationand data operations. The data structure imposes a physical organizationupon the collection of data stored within a memory storage device andrepresents specific electrical or magnetic elements.

[0059] For the purposes of this discussion, a method or process isgenerally conceived to be a sequence of computer executed steps leadingto a desired result. These steps generally require physicalmanipulations of physical quantities. In addition, it should beunderstood that the methods and systems described herein are not relatedor limited to any particular computer (standalone or distributed) orapparatus. Furthermore, the methods and systems are not related orlimited to any particular communication architecture. Thus, one skilledin the art will be able to implement the systems and methods of thepresent invention with general purpose machines or specially customizedprogrammable devices according to the teachings described herein.

[0060] Referring now to the drawings, in which like numerals representlike elements throughout the several figures, aspects of the presentinvention and the preferred operating environment are described.

[0061] Card Processing and Service Provider, Issuers, and Cardholders

[0062] The processing of a credit card transaction typically involvesthe cardholder, a merchant, a merchant acquirer, the card issuer, and acard processing and service provider. FIG. 1 illustrates an exemplaryrelationship between a card processing and service provider 100, anumber of issuers 102 a, 102 b . . . 102 c, and a number of cardholders120. The card processing and service provider 100 supports the issuersby authorizing and processing monetary transactions, as well asproviding support for creating new accounts, modifying accounts,generating cardholder statements, applying payments to accounts,controlling communications to cardholders and building reward programs.An issuer, such as, issuer 102 b, is typically a bank or other financialinstitution that issues one or more credit card products. The issuermanages transaction processing at the account level. An issuer typicallymanages a number of accounts using a hierarchy, such as theProduct/System, Principal, and Agent hierarchy shown in FIG. 1. Thecardholders 120 are typically individuals holding a credit card orcharge card, such as a VISA™, MASTERCARD™, or private label card. Inaddition to the elements shown in FIG. 1, additional elements (notshown) may also be included. For example, additional issuers,Products/Systems, Principals, and Agents may exist.

[0063] An issuer can issue different types and versions of credit cardproducts. For example, issuer 102 b could offer a VISA™ product and aMASTERCARD™ product. Each product could be offered in standard, gold andplatinum versions. The Product/System blocks shown in FIG. 1 correspondto different products. If issuer 102 b issues a VISA™ product and aMASTERCARD™ product, then Product/System 104 a could correspond to theVISA™ product and Product/System 104 b could correspond to theMASTERCARD™ product. An issuer typically uses either a BIN (bankidentification number) or an IIN (issuer identification number) toidentify its different credit card products.

[0064] Issuers typically use additional levels of reporting structuresbelow the Product/System level to manage large portfolios. FIG. 1illustrates that below the Product/System level is the Principal leveland below the Principal level is the Agent level. The divisions betweenthe Principal level and the Agent level are typically defined by theissuer. Some issuers use the Principal level and the Agent level to makegeographical divisions. For example, Principal block 106 a couldcorrespond to a geographic region, such as the southeast, and Agentblock 110 a could correspond to a state within that region. Thecardholders 120 are located below the Agent level. As shown in FIG. 1, anumber of cardholders can be associated with a single Agent. FIG. 1illustrates an example of the hierarchical relationships that existbetween an issuer and a cardholder. As will be apparent to those skilledin the art, alternative hierarchies are also possible.

[0065] An individual can hold a number of different cards correspondingto a number of different accounts. Although the same cardholder isassociated with each of the accounts, each account is processedindependently by the issuer. If several cardholders are in the samefamily, then each cardholder may hold several cards. In the case of afamily, the cardholders may be related and the payments may be made fromfamily funds, but each account is still processed independently. Forexample, Table 1 illustrates the credit cards held by a typical family.TABLE 1 STANDARD STANDARD GOLD PRIVATE Cardholder VISA ™ MC MC LABELMOTHER Account 1 Account 2 FATHER Account 3 Account 4 SON Account 5DAUGHTER Account 6 Account 7 GRAND- Account 8 FATHER

[0066] Each of the accounts shown in Table 1 is an independent accountfrom the issuer's perspective. The standard MASTERCARD™ accountassociated with the daughter (Account 6) is independent of the standardMASTERCARD™ account associated with the grandfather (Account 8) and thegold MASTERCARD™ account associated with the mother (Account 2) isindependent of the gold MASTERCARD™ account associated with the father(Account 3). The processing options used by the issuer to process theaccounts shown in Table 1 can differ by product.

[0067] The relationships between the different accounts shown in Table1, the issuer, and the card processing and service provider areillustrated by FIG. 2. The card processing and service provider 200supports the issuer 202. The issuer 202 issues a variety of credit cardproducts, including a standard VISA product 204 a, a standardMASTERCARD™ product 204 b, a gold MASTERCARD™ product 204 c, and aprivate label product 204 d. Account 1 and Account 5 are shown under thestandard VISA product 204 a, Account 6 and Account 8 are shown under thestandard MASTERCARD™ product 204 b, Account 2 and Account 3 are shownunder the gold MASTERCARD™ product 204 c, and Account 4 and Account 7are shown under the private label product 204 d.

[0068] Groups and Group Relationships

[0069] In accordance with an embodiment of the present invention, theaccounts shown in Table 1 and FIG. 2 can be linked together to create agroup. A group can include a number of accounts that correspond to asingle issuer. By linking accounts into a group, group processing can beperformed on the accounts that are members of the group whilemaintaining independent processing of each of the accounts. Each grouphas a primary owner. Generally the primary owner corresponds to acardholder for a key account. For example, the standard VISA accountheld by the mother could be designated as the key account for the groupshown in Table 1 and FIG. 2. The remaining accounts in the group arereferred to as dependent accounts. The relationship between a dependentaccount and the group is independent of the relationship between theremaining dependent accounts and the group. Typically, the issuerdefines the possible relationships between a dependent account and thegroup.

[0070]FIG. 2 shows one possible organization for a group. Otherorganizations are also possible. As shown in FIG. 2, the accounts in agroup can be associated with different products. There are norestrictions on the placement of the accounts in a group at theProduct/System, Principal or Agent levels. The accounts in a group canbe split between different Products/Systems, Principals and Agents. Thekey account and a dependent account can be associated with the sameAgent. Multiple dependent accounts can also be associated with the sameAgent. The accounts associated with an Agent are not required to be inthe same group (or any group at all).

[0071]FIG. 3 shows an exemplary group where the key account andDependent Account 1 are associated with the same Agent 308 a. DependentAccount 2 is associated with a different Agent 308 b, but is the sametype of product 304 a as the key account and Dependent Account 1.Dependent Account 3 is associated with a different Principal 306 b thanthe key account, Dependent Account 1, and Dependent Account 2, but isthe same type of product 304 a. Dependent Account 4 is associated with adifferent Agent 308 d than Dependent Account 3, but is associated withthe same Principal 306 b. Dependent Account 5 is a different product 304b than any of the other accounts in the group. Although FIG. 3 onlyshows a single group, additional groups or individual accounts can existunder the issuer 302 b. Furthermore, additional groups can exist underthe other issuers 302 a, 302 c.

[0072] Linking the accounts into a group is accomplished by linking afinancial record that corresponds to each account to group master datafor the group. FIG. 4A illustrates the linking of the accounts shown inTable 1 into a group. The Group Master Data 400 includes informationabout the group, including group control settings, group aggregate data,and a group identifier. The Group Master Data 400 is discussed in moredetail below in connection with FIG. 4B. The Key Financial Record 402corresponds to the key or primary owner. The Key Financial Record 402can also correspond to a key account held by the primary owner. In thisexample, the Key Financial Record 402 corresponds to the standard VISAaccount held by the mother. The relationship 420 between the KeyFinancial Record 402 and the Group Master Data 400 is a predefinedrelationship. Typically, the relationship is defined in part by the cardprocessing and service provider and in part by the issuer.

[0073] In addition to the Key Financial Record, the group also includesDependent Financial Records 404, 406, 408, 410, 412, 414, and 416 thatcorrespond to the dependent accounts. Typically, a dependent account isassociated with each dependent financial record. For example, Account 2is associated with Dependent Financial Record 1 404. Each account isalso associated with one or more cardholders, e.g. the mother is thecardholder associated with Account 2.

[0074] The dependent accounts in the group can cross product lines. Inthis example, Account 2 and Account 3 are MASTERCARD™ products, Account4 and Account 7 are private label products, Account 5 is a VISA product,and Account 6 and Account 8 are MASTERCARD™ products. The relationship422 between Dependent Financial Record 1 404 and the Group Master Data400 is independent of the relationship between the remaining DependentFinancial Records and the Group Master Data.

[0075] The dependent accounts can also have different types ofownership. For example, the primary owner and a dependent cardholder canbe jointly responsible for a dependent account, the primary owner can beresponsible for a dependent account where a dependent cardholder is anauthorized user, or a dependent cardholder can be solely responsible fora dependent account. In addition, a dependent cardholder can be jointlyliable with the primary owner for the group liability. If a dependentcardholder is jointly liable with the primary owner for the group, thenthe dependent account is a jointly liable dependent account.

[0076] Group Master Data

[0077] The Group Master Data 400 is further illustrated in FIG. 4B. FIG.4B illustrates a number of files 402-428. Each of the files includesrecords that contain information about the group and the accounts thatare members of the group. The Group Data file 404 includes informationabout the group, such as a group identifier, a group cycle code, a groupcredit line, group available credit, and a group collector code. Thegroup identifier identifies the group. Each of the records associatedwith the group includes the group identifier.

[0078] A group cycle code indicates the cycle code for the group. If thegroup includes a key account, then the cycle code for the key accounttypically is used as the group cycle code. If the group does not includea key account, then the group cycle code can be a default cycle code orcan be based upon the cycle code of one of the dependent accounts in thegroup. The group credit line specifies the credit available for theaccounts in the group that authorize against the group credit line. Thegroup available credit specifies the current credit available for theaccounts in the group that authorize against the group credit line. Thegroup collector code may be set once a collector is assigned to one ofthe accounts in the group. A collector may be assigned because theaccount is delinquent. If another account in the group becomesdelinquent, then the group collector code is checked and the samecollector is assigned to that account if a group collection option isused.

[0079] The Primary Owner file 402 includes information about the primaryowner of the group. The primary owner is the individual that is liablefor the group. If more than one individual is liable for the group, thenthose individuals are jointly liable for the group and information aboutthe individuals in stored in the Primary Owner file 402. For example, aprimary owner and a dependent cardholder could be jointly liable for thegroup. For simplicity, the term “primary owner” is used herein toinclude a single primary owner or joint primary owners. Every group hasa primary owner. If the group includes a key account, then the keycardholder is the primary owner.

[0080] The Group Member file 408 includes a record for each of theaccounts that is (or was) a member of the group. Each record includes anaccount number, an indication as to whether the account is a key accountor a dependent account, and group membership information. A record ismaintained for an account in the Group Member file 408 even if theaccount is delinked from the group. Each record includes groupmembership information which indicates when the account was linked tothe group and if the account is no longer a member of the group, whenthe account was delinked from the group. The Address file 406 includes arecord for each of the accounts that is (or was) a member of the group.Each record includes the mailing address of the cardholder associatedwith the account.

[0081] The Member Relationship file 410 includes a record for each ofthe accounts that is (or was) a member of the group. A memberrelationship record contains information about the strategy associatedwith an account. If the strategy associated with the account haschanged, then the member relationship record contains information aboutthe previous strategy or strategies, as well as the current strategy.The member relationship record also contains information about theeffective dates of each strategy.

[0082] The Strategy Definition file 412 includes a record for each ofthe defined strategies. The strategy definition records include theparameters and the parameter values that define the strategies referredto in the member relationship records. If the definition of a strategyhas changed, then the strategy definition record for that strategy alsoincludes the parameter and the parameter values that defined theprevious version or versions of the strategy, as well as the effectivedates of each strategy definition.

[0083] The Member Statement file 411 includes records for each accountthat is (or was) a member of the group. Each record includes a number offields that store statement data (monetary information) for theassociated account. In addition, each record includes a flag thatindicates whether the associated account cycles with the group (i.e. hasthe same cycle code as the group) or cycles independently. Theinformation stored in the Member Statement file 411 is used to generatethe group statement, dependent cardholder statement, and/or a courtesystatement.

[0084] The Group Statement file 418 includes records that contain groupmonetary and group non monetary information. The group monetaryinformation includes the group balances, as well as the group creditline and group available credit for a particular statement. The groupnon monetary information includes the group payment due date. Typically,the group payment due date is the earliest due date of all the accountsof the group that are paid by the primary owner. The information storedin the Group Statement file 418 is used to generate the group statement.

[0085] The information in the Member Statement file 411 and the GroupStatement file 418 is used to determine the initial break up of a grouppayment. The information is also used to support the on line display ofstatement information to an operator.

[0086] The Group Rewards file 414 includes a record for each of thereward programs for the group. Each record includes information aboutthe reward program, such as a reward program identifier and the amountof group points accumulated in that reward program.

[0087] The Custom Calculation Definition file 416 and the CustomCalculation Values file 420 support customized group calculations thatappear in a field on the group statement. Each custom calculationdefinition record includes a formula for a customized group calculation.Typically, a formula specifies that a customized group calculation iscalculated using monetary elements from the accounts in the group. Thevalue that is calculated using the formula is stored in a customcalculation values record.

[0088] The Group Payment file 422 includes a record for each grouppayment received. Each record includes the amount of the group paymentand the date the group payment was received. The Payment Allocationsfile 426 includes a record for each group payment received. Each recordindicates how the group payment was allocated among the accounts in thegroup. The Group Reversal file 424 includes a record for each grouppayment that has been reversed. If a group payment is reversed, then thereversal is made by referencing the Payment Allocation file 426 todetermine how the payment was originally allocated.

[0089] The Rejects file 428 includes records of rejections detectedduring processing other than group processing. A record in the Rejectsfile 428 includes a rejection report that provides details of therejection. As will be apparent to those skilled in the art, the filesshown in FIG. 4B are exemplary group master data files. The group masterdata could be stored using alternative types of files and records.

[0090] Dependent Strategies

[0091] Typically, the relationship shown in FIG. 4A between theDependent Financial Records 422, 424, 426, 428, 430, 432, 434 and theGroup Master Data 400 is defined by a set of parameters. The parametersare typically provided by the card processing and service provider. Aset of parameters and parameter values can be selected to create acustomized dependent strategy. Either the card processing and serviceprovider or the issuer can select the parameters and the parametervalues to create a dependent strategy. Preferably, the card processingand service provider provides parameters and the issuer selects a set ofparameter values that is suitable for a particular situation.Alternatively, the card processing and service provider could providestrategies rather than parameters to define the strategies. If the cardprocessing and service provider provides strategies, then each of theissuers supported by the card processing and service provider choosesamong the same group of strategies. However, if the card processing andservice provider provides parameters, then each issuer can customize thestrategies offered to its customers. In some embodiments the dependentstrategies are labeled. For example, a dependent strategy for acollege-age child residing at school may have one label, whereas adependent strategy for a second account for the primary owner may haveanother label.

[0092] A dependent strategy specifies the relationship between adependent account and the group by specifying group processing optionsfor the account. The group processing options provide flexibility in therelationships between the dependent accounts and the group and providefor automatic processing at the group level. Typically, the dependentstrategy includes parameters that define how transactions are authorizedfor the dependent account, as well as whether payment for the account isdue from the primary owner or from the dependent account cardholder. Inaddition the dependent strategy includes options for paymentapplication, statement generation, cardholder communications, and rewardpooling.

[0093] The parameter values could be selected to create a dependentstrategy appropriate for a dependent, college age child that resides atschool. The parameter values could be selected so that the child isliable for the account and the parent receives information about theactivity of the account. Alternatively, the parameter values could beselected so that the parent and the child are jointly liable for theaccount and that both the parent and the child receive information aboutthe activity of the account at their respective residences. Anotherstrategy could be created for a high school age child living at home.The parameter values could be selected so that the primary owner,typically the parent, is financially liable for the account and theaccount has a predetermined limit. The primary owner could set the limiton the account.

[0094] The parameter values could also be selected to create a strategyfor a dependent account held by the primary owner. The primary ownercould use the key account and the dependent account to segregateexpenses. The parameter values could be selected so that the primaryowner is liable for the account and detailed information about theaccount is included on the group statement. As will be apparent to thoseskilled in the art, additional strategies can also be created to addressthe needs of other situations.

[0095] Creating a Group

[0096] There are a number of ways that a group can be created. One wayto create a group is to create a group using new accounts. Another wayto create a group is to link a number of existing accounts together.Typically, a group is created by an issuer. The group can be createdusing either on line or batch processing. Once the first account isidentified as being a member of the group, the group master data isautomatically generated. Once a group is created, additional accountscan be added to the group or existing accounts can be removed from thegroup.

[0097] Business rules are used to insure that the relationships betweenthe accounts in the group are valid. The business rules define the typesof accounts that can be linked together in a group. Typically, thebusiness rules are promulgated by the card processing and serviceprovider. The business rules are checked whenever group relationshipsare impacted. For example, the business rules are checked when a groupis created or an account is added to or removed from a group. Shownbelow is a list of typical business rules. As will be apparent to thoseskilled in the art, the number and types of business rules may vary fromthat shown below.

[0098] (1) A group must have one and only one primary owner.

[0099] (2) A group will not exist without at least one account linked toit or a historical relationship to an account.

[0100] (3) Dependent accounts must have dependent strategies.

[0101] (4) All accounts that statement together must have the same cyclecode and method.

[0102] (5) All accounts in the group must have the same issuer number.

[0103] (6) Accounts within a group cannot be dual. A dual account is anaccount that corresponds to two different credit card products. Forexample, a dual account could correspond to a VISA product and aMASTERCARD™ product.

[0104] (7) Accounts within a group cannot be included in a CombineAccount Transfer. A Combine Account Transfer is a process that mergestwo accounts into a single joint account.

[0105] (8) Accounts in the group cannot have a commercial cardrelationship.

[0106] (9) The key account cannot have a status of bankrupt, closed orcharge off without impacting the dependent accounts.

[0107] Creating a Group Using New Accounts

[0108] An exemplary method for creating a group using new accounts isshown in FIG. 5. In step 500, a new account is opened. The new accountis designated as the key account in step 502 by setting a relationshipparameter for the account to “key.” The relationship parameter definesthe relationship between the account and the group. When the key accountis opened, a number of account parameters and group parameters areautomatically set. For example, parameters defining the cycle code andmethod and the currency code are typically defined at the time theaccount is opened. In step 504, the parameters set in step 500 arecompared to the set of business rules. If the parameters set in step 500satisfy the business rules, then the business rules are validated.

[0109] If the determination in step 504 is that the business rules arevalidated, then the “Yes” branch is followed to step 508. In step 508,the group build is initiated and the key financial record and the groupmaster data are created. Typically, the key financial record includesthe account parameters for the key account plus the relationshipparameter and a group identifier. The group master data includes a groupidentifier and certain group parameters. If the determination in step504 is that the business rules are not validated, then the “No” branchis followed to step 520 and an error occurs.

[0110] Although FIG. 5 illustrates that a key account is created insteps 500 and 502, a group can be created without a key account. If akey account is created, then the key account cardholder is the primaryowner. However, if a group is created without a key account, a primaryowner is required. A key financial record is created regardless ofwhether the group includes a key account.

[0111] The remaining steps in FIG. 5 illustrate adding dependentaccounts to the group. In step 510, a determination is made as towhether a dependent account is to be added to the group. If a dependentaccount is to be added to the group, then the “Yes” branch is followedto step 512 and a new account is opened. The new account is designatedas a dependent account by setting the relationship parameter for theaccount to dependent. From step 512, the method proceeds to step 514where a dependent strategy is selected. Typically, an issuer provides anumber of dependent strategies that can be used for dependent accountswithin a group. Once a dependent strategy is selected, then adetermination is made in step 516 as to whether the parameters selectedin opening the dependent account and the dependent strategy satisfy thebusiness rules. If the business rules are satisfied, then the businessrules are validated in step 516 and the method proceeds to step 518. Instep 518, the dependent financial record is created and the group masterdata is updated. Typically, the dependent financial record includesaccount parameters for the dependent account, as well as therelationship parameter, a group identifier, and a dependent strategyidentifier. Updating the group master data includes creating the linkbetween the dependent financial record for the dependent account and thegroup master data.

[0112] From step 518 the method returns to step 510 and a determinationis made as to whether another dependent account is to be added. Ifanother dependent account is to be added, then steps 512, 514, 516, and518 are repeated. Once all the dependent accounts have been added, thenthe method proceeds from step 510 via the “No” branch to step 506 andthe method ends.

[0113]FIG. 5 illustrates that business rules are validated after the keyaccount or a dependent account is opened. Alternatively, if the accountsare opened in an on line environment, then the business rules can bevalidated as the accounts are opened. For example, an operator can beprevented from creating an invalid relationship, such as creating twokey accounts. FIG. 5 also illustrates that the group master data isupdated after the addition of each dependent account. However, the groupmaster data can be updated at other times. For example, information foropening a key account and dependent accounts may be collected by theissuer and then submitted by the issuer to the card processing andservice provider in batch. If the information is submitted in batch,then the group master data may be updated once with information for allof the accounts in the group.

[0114] Creating a Group Using Existing Accounts

[0115]FIG. 6 illustrates the steps for creating a group using existingaccounts. In step 600, an existing account is selected as the keyaccount by setting the relationship parameter for the account to key. Ifthe account was not previously a member of a group, then therelationship parameter was blank. Once an existing account is selectedas the key account, then in step 602 a determination is made as towhether the business rules are validated. The business rules arevalidated if the parameters for the key account satisfy the businessrules.

[0116] If the business rules are validated, then the method follows the“Yes” branch to step 604. In step 604, the group build is initiated.Initiating the group build includes creating the group master data, andlinking the key account to the group by linking the key financial recordto the group master data.

[0117] Once the initial group build is complete, then a determination ismade in step 606 as to whether a dependent account is to be added to thegroup. If a dependent account is to be added to the group, then the“Yes” branch is followed to step 608. In step 608, an account isselected as a dependent account. Once an account is selected as adependent account, the relationship parameter for the selected accountis set to dependent. In step 610, a dependent strategy is selected forthe dependent account. From step 610 the method returns to step 606 anda determination is made as to whether another dependent account is to beadded to the group.

[0118] Once all the dependent accounts have been added to the group,then the “No” branch is followed from step 606 to step 612. In step 612,a determination is made as to whether the business rules are validated.The business rules are validated in step 612, if the dependent accountssatisfy the business rules. If the business rules are validated in step612, then the “Yes” branch is followed to step 614. In step 614, thegroup master data is updated with information for the dependentaccounts. In addition, the dependent financial records for the dependentaccounts are linked to the group master data. However, if the businessrules are not validated in step 612, then the “No” branch is followed tostep 616 and an error occurs.

[0119] Although FIG. 6 illustrates that the group master data is updatedafter all the dependent accounts have been selected, those skilled inthe art will appreciate that the group master data could be updated atother points in the process. For example, if the group is being createdusing on line processing, then validating the business rules andupdating the group master data could occur after step 610 for eachdependent account added.

[0120] Changing Group Relationships

[0121] The relationships between the accounts of the group are flexibleand can be modified. The relationship between a dependent account andthe group can be changed by selecting a new dependent strategy. Theability to modify, the dependent strategy allows the account to changeas the cardholder's situation changes. For example, if the initialdependent strategy was a strategy suitable for a high school age childliving at home, then the dependent strategy could be modified to astrategy suitable for a college age child living at school once thechild enters college and moves away from home. Changing the dependentstrategy of one of the dependent accounts does not impact the dependentstrategies of the other dependent accounts.

[0122] In addition, a dependent account can be added to the group ordeleted from the group without affecting the remaining accounts in thegroup. The ability to add dependent accounts and delete dependentaccounts allows the group to change to accommodate changes in therelationships between the primary owner and the dependent cardholders.To add a dependent account to a group, the dependent financial recordfor the dependent account is linked to the group master data. Adding adependent account to a group may correspond to the primary owner or adependent cardholder obtaining another card or may correspond to addinganother dependent cardholder to the group. For example, a group could beestablished for a family that includes a mother, father and daughter.When the group is created, the group could include financial recordscorresponding to accounts held by the mother and father. Subsequently, adependent financial record could be added for an account for thedaughter.

[0123] To remove a dependent account from a group, the dependentfinancial record for the dependent account is delinked from the groupmaster data. Removing a dependent account from a group may correspond toa change in family status. For example, a group could be established fora married couple with the husband as the primary owner and the wife as adependent cardholder. If the couple divorces, then the group could bemodified to delete the dependent financial records that correspond toaccounts held by the wife. As will be apparent to those skilled in theart, a dependent account can also be removed from a group for reasonsother than a change in family status.

[0124] A single account can be removed from a group or a number ofaccounts can be removed from a group. If an account is removed from agroup, it can be moved to an existing group, used to create a new group,or can be designated as an independent account that is not a member ofany group. If a dependent account is moved to an existing group, thenthe group identifier in the dependent financial record is changed tocorrespond to the group identifier for the existing group. If adependent account is removed from one group and is used to createanother group, then the dependent account can remain a dependent accountor can be “matured” into a key account. To mature a dependent accountinto a key account, the relationship parameter for the dependent accountis changed from dependent to key. If a dependent account is matured intoa key account, the history for the dependent account that was accruedduring the period that the dependent account was a member of the groupfollows the dependent account to the new group. If the dependent accountis designated as an independent account, then the relationship parameteris set to blank.

[0125] If all the accounts in a group are removed from the group, thenthe group continues to exist for some pre defined period of time eventhough the group does not have any members. The group continues to existso that audit history for the group can be maintained for the predefinedperiod of time.

[0126] The primary owner of the group can be changed. The primary ownercan be changed to a cardholder that corresponds to one of the dependentaccounts or to a new primary owner. To change the primary owner to adependent cardholder, the relationship parameter for the dependentaccount is changed from dependent to key. The original key account canbe converted to a dependent account by changing the relationshipparameter from key to dependent. Alternatively, the original key accountcan be removed from the group and transferred to another group (aseither a key or dependent account) or established as an individualaccount in a manner similar to that described in the precedingparagraph.

[0127] A group history is maintained in the group master data. Forexample, as discussed above in connection with FIG. 4B, information onall the accounts that are or ever were members of the group are storedin the Group Member file. The history of any changes in the dependentstrategy for a dependent account are maintained in the MemberRelationship file and the history of any changes in the definition of astrategy is maintained in the Strategy Definition file. In addition togroup history, account history is also maintained with each account. Theaccount history follows the account notwithstanding changes in theaccount's membership in a group. For example, payment history for adependent account follows the dependent account even if the dependentaccount is delinked from the group and is established as an individualaccount.

[0128] Adding a Dependent Account to a Group

[0129] Once a group is created, additional dependent accounts can beadded to the group. The additional dependent accounts can be newlycreated accounts or can be existing accounts. FIG. 7A illustrates thesteps for adding a dependent account to an existing group. In step 700,a group is identified. Typically a group is identified using the groupidentifier. In step 702, a determination is made as to whether anexisting account is to be added or whether a new account is to be added.If a new account is to be added, then the “Yes” branch is followed tostep 704. In step 704, a new account is opened and the relations hipparameter for the account is set to dependent. A dependent strategy forthe new account is selected in step 706. In step 708, a determination ismade as to whether the dependent account opened in step 704 satisfiesthe business rules. If the dependent account satisfies the businessrules, then the business rules are validated and the “Yes” branch isfollowed to step 710. In step 710, the group master data is updated. Ifthe business rules are not validated in step 708, then the “No” branchis followed to step 722 and an error occurs.

[0130] If the determination in step 702 is that an existing account isto be added, then the “No” branch is followed to step 712. In step 712,an existing account is selected and the relationship parameter for theaccount is set to dependent. A dependent strategy for the account isselected in step 714. The parameters for the dependent account createdin step 712 are compared to the business rules in step 718. If theparameters for the dependent account satisfy the business rules, thenthe business rules are validated and the “Yes” branch is followed tostep 720. In step 720, the group master data is updated. However, if thebusiness rules are not validated then the “No” branch is followed tostep 722 and an error occurs.

[0131] Although FIG. 7A indicates that the group master data is updatedafter each dependent account is added to the group, the group masterdata can be updated at other points in the process. For example, ifmultiple accounts are to be added to an existing group, then the stepsshown in FIG. 7A would be repeated for each account. Rather thanupdating the group master data after the addition of each dependentaccount, the group master data could be updated after the addition ofall the dependent accounts. Updating the group master data after theaddition of each account can be used to support on line processing,whereas updating the group master data after the addition of a number ofdependent accounts can be used to support batch processing.

[0132] Group Processing

[0133] Once a group is created it can be used to perform groupprocessing. Group processing typically includes authorizingtransactions, applying group payments, creating group statements,controlling cardholder communications, and administering reward programsfor the accounts in the group. Information from both the key account andthe dependent accounts are used for group processing. Each dependentaccount has an associated dependent strategy that specifies groupprocessing options for the dependent account. Although the accounts of agroup are subject to group processing for some functions, the accountsare treated as individual accounts for other functions.

[0134] Authorizing a Transaction

[0135] The dependent strategy for a dependent account specifies theauthorization option for the dependent account. The authorization optionspecifies the information that is used to authorize a transaction. Inone embodiment of the invention, three authorization options areavailable for a dependent account. One authorization option considersonly the credit line and available credit of the group, a second optionconsiders only the credit line and available credit of the dependentaccount, and a third option considers the credit line and the availablecredit of both the group and the dependent account.

[0136] Depending upon the authorization option selected, theauthorization processing uses the group credit line and the groupavailable credit and/or the dependent credit line and the dependentavailable credit. The group credit line is a group parameter thattypically is set when the group is created. The dependent credit line isa dependent account parameter that is set when the dependent account isopened. The group credit line and the dependent credit line can bemodified. The group available credit is calculated real time usingactivity from the key account (if any) and any dependent accounts thatshare the group credit line. A dependent account shares the group creditline if payment for the dependent account is due from the primary owner.Generally, the group available credit is calculated by subtracting thecurrent balances and any outstanding authorizations of the key accountand the dependent accounts that share the group credit line from thegroup credit line. Similarly, the dependent available credit iscalculated by subtracting the current balance and any outstandingauthorizations of the dependent account from the dependent credit line.

[0137]FIG. 7B illustrates exemplary steps for authorizing a transaction.In step 740, an authorization request is received. The authorizationrequest includes a transaction amount and an account identifier, such asan account number. In step 742, a determination is made as to whetherthe account identifier corresponds to an account that is a member of agroup. If the requesting account is not a member of a group, then the“No” branch is followed to step 752. In step 752, normal authorizationprocessing occurs using the credit line and the available credit for theaccount.

[0138] Normal authorization processing typically includes severalcalculations that use the credit line and the available credit. Forexample, authorization may include comparing the amount of thetransaction to the available credit, comparing the amount of thetransaction to a percentage expansion of the credit line, as well ascomparing the transaction to past transactions for the account.Comparing the transaction to past transactions for the account may beused to detect possible fraudulent uses of a card and may result in theissuance of a referral code. As will be apparent to those skilled in theart, additional calculations can also be performed.

[0139] If the determination in step 742 is that the requesting accountis a member of a group, then the “Yes” branch is followed to step 744.In step 744, a determination is made as to whether the requestingaccount is a key account or a dependent account. If the requestingaccount is a key account, then the “Yes” branch is followed to step 748.In step 748, normal authorization processing occurs using the groupcredit line and the group available credit.

[0140] If the determination in step 744 is that the requesting accountis a dependent account, then the “No” branch is followed to step 746. Instep 746, the dependent strategy is checked to determine theauthorization option that corresponds to the dependent account. FIG. 7Billustrates three possible authorization options, A, B and C. Option Aspecifies that the credit line and the available credit for the groupare used for authorization processing. Option B specifies that thecredit line and the available credit for both the group and thedependent account are used for authorization processing. Option Cspecifies that the credit line and the available credit for thedependent account are used for authorization processing.

[0141] If the dependent strategy specifies option A, then the methodproceeds from step 746 to step 748 and the credit line and the availablecredit for the group are used for normal authorization processing. Ifthe dependent strategy specifies option C, then the method proceeds fromstep 746 to step 752 and the credit line and the available credit forthe dependent account are used for normal authorization processing. Thedifference between the authorization processing performed in step 748and the authorization processing performed in step 752 is that step 748uses group information, whereas step 752 uses dependent accountinformation.

[0142] If the dependent strategy specifies option B, then the methodproceeds from step 746 to step 750 and the credit line and the availablecredit for both the group and the dependent account are used forauthorization processing. In step 750, the credit line and the availablecredit for the dependent account are used in normal authorizationprocessing. The authorization processing performed in step 750 issimilar to that performed in step 752. However, additional processing isrequired for option B. In step 754, a determination is made as towhether the processing performed in step 750 indicates that theauthorization request is authorized. If the processing performed usingthe dependent account information indicates that the request isauthorized, then the “Yes” branch is followed to step 758. In step 758,a determination is made as to whether the transaction amount specifiedin the authorization request exceeds the group available credit. If theamount does not exceed the group available credit, then the “Yes” branchis followed to step 760 and the authorization request is approved. Ifthe processing performed in step 754 indicates that the authorizationrequest is denied or if the comparison performed in step 758 indicatesthat the amount of the request exceeds the group available credit, thenthe “No” branch is followed to step 756 and the authorization request isdeclined.

[0143] Applying a Payment

[0144] The dependent strategy for a dependent account specifies whetherpayment of the dependent account balance is due from the primary owneror is due from the dependent cardholder. If payment of the dependentaccount is due from the dependent cardholder, then the entire amount ofa payment received from the dependent cardholder is credited to thedependent account. However, if the dependent account is paid by theprimary owner, then the amount of the group payment that is credited tothe dependent account depends upon the amount of the group payment, aswell as the control settings for the group. Payment of the key accountis due from the group payment.

[0145] The allocation of a group payment is partially determined by theamount of the payment and partially determined by the group paymentoptions. The group payment options are typically set by the issuer. Thegroup payment options could be part of the group control settings in thegroup master data. Alternatively, the group payment options could bestored in a separate file, such as a Product Control File, andassociated with the group through the key account or through anothermeans.

[0146] Only accounts included in the group balances during theprocessing of the last group statement are included in the automaticallocation of a group payment. The group balances for the last groupstatement can be determined from the Group Statement files in the groupmaster data. The account balances for accounts in the group can bedetermined from the Member Statement files in the group master data.

[0147] Typically, the amount of the group payment is compared to one ormore of the group balances. The group balances include the LastStatement Balance (“LSB”) and the Minimum Payment Due (“MPD”) for thegroup. The group balances may also include the group delinquency amount.The group LSB is determined by adding the LSB of the key account (ifany) to the LSB of all dependent accounts in the group that are paid bythe primary owner. If payment for a dependent account is due from thedependent cardholder, then the LSB of that dependent account is notincluded in the group LSB. The group MPD is calculated by adding the MPDfor the key account (if any) to the MPD for each of the dependentaccounts that are paid by the primary owner. The group delinquencyamount is determined by adding the account delinquency of the keyaccount (if any) to the account delinquency of the dependent accountsthat are paid by the primary owner.

[0148]FIGS. 8A and 8B illustrate an exemplary method for applying agroup payment. In step 800, the group payment is received. Adetermination is made in step 802 as to whether the payment is less thanthe group LSB. If the group payment is greater than or equal to thegroup LSB, then the “No” branch is followed to step 804. In step 804,the payment is applied to the dependent accounts in an amount equal tothe LSB for each account. The remainder of the group payment is appliedto the key account in step 806. If the payment is equal to the groupLSB, then the amount applied to the key account is step 806 is equal tothe LSB of the key account. However, if the group payment is greaterthan the group LSB, then the amount applied to the key account in step806 is greater than the LSB of the key account. Although FIG. 8Aillustrates that any overpayment is credited to the key account, anoverpayment could be shared between the accounts of the group. Whetheran overpayment is credited to the key account or shared between theaccounts is typically determined by the group payment options.

[0149] If the determination in step 802 is that the group payment isless than the group LSB, then the “Yes” branch is followed to step 808.In step 808, a determination is made as to whether the group payment isless than the group MPD. If the group payment is less than the groupMPD, then the “Yes” branch is followed to step 810. In step 810, thegroup payment options are determined. In step 812, a determination ismade as to whether the group payment options indicate that accountdelinquency is considered in applying a group payment. If accountdelinquency is not considered, then the “No” branch is followed to step814. In step 814, MPD ratios are calculated for the key account and thedependent accounts that are paid by the primary owner. An MPD ratio iscalculated for an account by comparing the MPD for the account with thegroup MPD. Once the MPD ratios for the key account and the dependentaccounts that are paid by the primary owner are calculated in step 814,then in step 816 the payment is applied to the key account and thedependent accounts in the group in accordance with the MPD ratioscalculated in step 814.

[0150] If the determination in step 812 is that account delinquency isconsidered in applying the group payment, then the “Yes” branch isfollowed to step 820. In step 820, the group payment is applied to thekey account and the dependent accounts paid by the primary owner tosatisfy the delinquent amount for each account. In step 822, adetermination is made as to whether there is any amount of the paymentremaining. If there is an amount of the payment remaining, then the“Yes” branch is followed to step 814 and the remaining payment isallocated based upon the MPD ratios for the key account and thedependent accounts paid by the primary owner. If the determination instep 822 is that there is no remaining balance, then the method ends.

[0151] If the determination in step 808 is that the group payment isgreater than or equal to the group MPD, then the “No” branch is followedto step 830 of FIG. 8B. In step 830, the group payment is allocatedbetween the key account and the dependent accounts that are paid by theprimary owner to satisfy the MPD for each account. A determination ismade as to whether there is any amount of the group payment remaining instep 832. If there is an amount of the group payment remaining, then themethod proceeds to step 834. In step 834, a remaining balance ratio iscalculated for each of the accounts. A remaining balance ratio iscalculated by comparing the remaining balance for an account to theremaining balance for the group. The remaining balance for an account iscalculated by subtracting the MPD from the LSB for the account. Theremaining balance for the group is calculated by subtracting the groupMPD from the group balance. Once the remaining balance ratios arecalculated in step 834, then the remainder of the payment is applied inaccordance with the remaining balance ratios in step 836. If thedetermination in step 832 is that there is no remaining balance, thenthe method ends.

[0152] As will be apparent to those skilled in the art, other paymentratios could be considered when allocating a group payment among theaccounts in the group other than those shown in FIGS. 8A and 8B. Forexample, as an alternative to steps 814 and 816, the group payment couldbe allocated based upon a LSB ratio rather than an MPD ratio or basedupon an account hierarchy. An LSB ratio for an account can be calculatedby comparing the LSB for the account to the LSB for the group. Anaccount hierarchy specifies the order in which the accounts of a groupare to be paid. Similarly, MPD ratios could be used as an alternative tothe remaining balance ratios illustrated in FIG. 8B. Moreover, otheraccount conditions could be considered in allocating a group payment.For example, in addition to or as an alternative to consideringdelinquent amounts, disputed amounts could be considered.

[0153] The exemplary method for payment application illustrated by FIGS.8A and 8B is based upon the amount of the group payment, the dependentstrategies and the group payment options. Preferably, the stepsillustrated in FIGS. 8A and 8B can be overridden. For example, anoperator could manually allocate a group payment between the key accountand the dependent accounts in accordance with specific allocationinstructions. The allocation instructions could be generated by theprimary owner of the group or the issuer. If the group payment is anelectronic payment, then instructions submitted with the electronicpayment could determine how the payment is allocated. The allocationinstructions could be for a single payment or could be standinginstructions that apply to all payments received. If the allocationinstructions are standing instructions, then the instructions could bestored in the group master data.

[0154] There are times when the application of a group payment needs tobe reversed. For example, reversal of a payment is necessary if a checkfor the payment is returned for insufficient funds. If a check for agroup payment is returned for insufficient funds, then the paymentallocations to the accounts in the group are reversed. To reverse thepayment allocations, the original payment allocation must be recreated.For example, if a group payment of $100 was allocated $50 to the keyaccount, $25 to one dependent account and $25 to another dependentaccount, then reversal of the group payment is made by reversing the $50payment allocation to the key account, the $25 payment allocation to thefirst dependent account and the $25 payment to the second dependentaccount. To reverse a payment, the Payment Allocation file is used todetermine how the payment was originally allocated.

[0155] Generating Group Statements and Courted Statements

[0156] A group statement is created for the group and is sent to theprimary owner. The group statement includes information about theactivity of the key account (if any) and the activity of some or all ofthe dependent accounts of the group. The amount of information thatappears on the group statement about a dependent account is controlledby the dependent strategy. Depending upon the dependent strategy, thegroup statement can include details of the activity of the dependentaccount or a summary of the activity of the dependent account.

[0157] Statement data is calculated for each account in the group.Statement data typically includes the MPD, LSB, reward information,finance charges, and late fees for the account. The statement data iscalculated on an account by account basis. The statement data is used tocreate the group statement, a dependent statement, and/or a courtesystatement. The statement data is also used to calculate group data.

[0158] Group data includes the group MPD, group LSB, group rewardinformation, group available credit, group finance charges and grouplate fees. The group data is calculated from the key account and anydependent accounts that are paid by the primary owner. The groupstatement also includes information about the previous group payment,including the amount, the posting date, etc. The group statement alsoincludes information about the group, such as the primary owner, alisting of the accounts in the group, including the account numbers, andthe dependent strategy for each dependent account in the group.

[0159] A dependent strategy specifies whether payment for the dependentaccount is due from the primary owner or from a dependent cardholderassociated with the dependent account. The dependent strategy can alsospecify that a courtesy statement is generated. A courtesy statement isa statement that provides statement data to the cardholder, but does notrequire payment from the cardholder.

[0160]FIG. 9 illustrates exemplary steps for identifying the addresseesor intended recipients of statement data and for providing statementdata for inclusion on the group statement, a dependent statement, and acourtesy statement. In step 900, statement data for the key account (ifany) and the dependent accounts are calculated. If the group includes akey account, then the statement data for the key account is provided forthe group statement in step 900. In step 904, the dependent strategy fora dependent account is checked to determine whether payment for thedependent account is due from the primary owner or from a dependentcardholder associated with the dependent account.

[0161] If payment for the dependent account is due from the primaryowner, then the “Yes” branch is followed to step 908. In step 908, theprimary owner of the group is identified as an intended recipient of thestatement data for the dependent account and the statement data for thedependent account is provided for inclusion on the group statement. Instep 910, a determination is made as to whether the dependent strategyspecifies that the dependent cardholder receives a courtesy statement.If the dependent strategy specifies that the dependent cardholderreceives a courtesy statement, then the “Yes” branch is followed to step912. In step 912, the dependent cardholder is identified as anotherintended recipient of the statement data for the dependent account andthe statement data for the dependent account is provided for inclusionon the dependent statement. If the determination in step 910 is that thedependent strategy does not specify that the dependent cardholderreceives a courtesy statement, then the “No” branch is followed to step914 and the method ends.

[0162] If payment for the dependent account is due from a dependentcardholder associated with the dependent account, then the “No” branchis followed to step 916. In step 916, the dependent cardholder of thegroup is identified as an intended recipient of the statement data forthe dependent account and the statement data for the dependent accountis provided for inclusion on a statement for the dependent cardholder.In step 918, a determination is made as to whether the dependentstrategy specifies that the details of the activity of the dependentaccount are included on the group statement. If the details of theactivity of the dependent account are included on the group statement,then the “Yes” branch is followed to step 920. In step 920, the primaryowner is identified as another intended recipient of the statement datafor the dependent account and the statement data for the dependentaccount is provided for inclusion on the group statement. If thedependent account statements on the same day as the group, then currentstatement data is provided for inclusion on the group statement.However, if the dependent account statements on a different day than thegroup, then statement data associated with the last dependent statementis provided for inclusion on the group statement.

[0163] If the determination in step 918 is that the details of theactivity of the dependent account are not included on the groupstatement, then the “No” branch is followed to step 922. In step 922,the primary owner is identified as another intended recipient of thestatement data for the dependent account and a summary of the statementdata for the dependent account is provided for inclusion on the groupstatement.

[0164] Step 904 illustrates that the dependent strategy for a dependentaccount is checked. As will be apparent to those skilled in the art, ifthe group includes multiple dependent accounts, then steps 904 through922 are repeated for each dependent account.

[0165] Cardholder Communications

[0166] The dependent strategy for a dependent account also providescardholder communication options for the dependent account. Thecommunication options specify the intended recipient of an originalcommunication, such as a letter, notice, or plastic, and, in the case ofletters or notices, specify whether a courtesy copy of the communicationis provided. A communication is typically generated to provideinformation to the cardholder. For example, a communication can begenerated to advise a cardholder of changes to the cardholder agreementor to advise a cardholder of special offers.

[0167] The dependent strategy can specify that the originalcommunication is sent to the primary owner. The dependent strategy canalso specify that a courtesy copy of the communication is sent to thedependent cardholder. Alternatively, the dependent strategy can specifythat the original communication is sent to the dependent cardholder. Ifthe dependent strategy specifies that the original communication is sentto the dependent cardholder, the dependent strategy can also specifythat a courtesy copy of the communication is sent to the primary owner.

[0168] In some instances, it may be necessary to generate multiplecourtesy copies. This situation may occur if two parties are jointlyliable on an account. For example, a dependent account could be jointlyheld by a first dependent cardholder and a second dependent cardholder.If the dependent strategy specifies that the first dependent cardholderreceives the original communication and that the primary owner receivesa courtesy copy, then in addition to the courtesy copy sent to theprimary owner, a second courtesy copy is sent to the second dependentcardholder because the account is jointly held.

[0169] If the group includes multiple dependent accounts, then thedependent strategies for the dependent accounts can specify that theprimary owner is to receive the original communication or a courtesycopy. Preferably, it is recognized that multiple communications arebeing sent to the primary owner so that the communications can be mergedinto a single communication that includes the communications for all thedependent accounts.

[0170] A group communication can include information about some or allof the accounts within a group. Typically, a group communication is sentto the primary owner of the group. Information about selected accountsof the group is obtained from the financial records corresponding to theaccounts. The type of information obtained from the financial recordscan vary according to the type of communication. Typically, the type ofinformation is specified by a processing option or variable associatedwith the communication. The information obtained from the financialrecords is combined into a single communication. The singlecommunication can be automatically generated.

[0171] A group communication can also be manually created. The groupcommunication can include information about the accounts within thegroup. To manually create a group communication, an operator can use aseries of on line screens to specify the accounts and the type ofinformation to be included in the communication.

[0172] In addition to letter communications, the primary owner and thedependent account cardholders may also receive notices. Notices areadded to a group statement by considering what notices are required forthe key account, what notices are required for each of the dependentaccounts, and what notices are optional for the key account and thedependent accounts. If several accounts require the same notice, thenpreferably the notices are reviewed to insure that no duplicates areincluded.

[0173] Pooling Reward Points

[0174] Reward programs allow cardholders to earn reward points based onpurchases and other account activity. The processing of reward points atthe group level is determined by the reward program and the dependentstrategies of the dependent accounts in the group. Typically, theavailability of group level pooling is determined by the reward program.It may be that some programs permit group pooling, whereas otherprograms do not. If the accounts in a group are members of multiplereward programs, then it is possible that some programs permit poolingwhile other programs do not.

[0175] If a reward program supports pooling, then any reward pointsearned by the key account are pooled into the group pool. The dependentstrategy specifies whether reward points earned by a dependent accountare pooled or are maintained at the account level. In addition, thedependent strategy specifies whether the dependent account cardholdercan redeem group reward points.

[0176] An exemplary method for redeeming group reward points is shown inFIG. 10. In step 1000, a request to redeem group reward points isreceived. In step 1002, a determination is made as to whether therequest is associated with an account that is a member of the group. Ifthe request is from an account that is a member of the group, then the“Yes” branch is followed to step 1004. In step 1004, a determination ismade as to whether the reward program supports pooling. If the rewardprogram supports pooling, then the “Yes” branch is followed to step1006. In step 1006, a determination is made as to whether the accountmaking the request is the key account. If the requesting account is thekey account, then the “Yes” branch is followed from step 1006 to step1012. However, if the requesting account is not the key account, thenthe requesting account is a dependent account and the “No” branch isfollowed from step 1006 to step 1008. In step 1008, the dependentstrategy for the requesting dependent account is checked. Adetermination is made in step 1010 as to whether the dependent strategyspecifies that the dependent account can redeem group reward points. Ifthe dependent account can redeem group reward points, then the “Yes”branch is followed to step 1012.

[0177] In step 1012, a determination is made as to whether there aresufficient group points to satisfy the redemption request. If there aresufficient points, then the “Yes” branch is followed to step 1018 andthe request to redeem group reward points is authorized. However, ifthere are not sufficient points, then the “No” branch is followed tostep 1014 and the redemption request is not authorized.

[0178] If the determination in step 1002 is that the request to redeemgroup reward points is made by an account that is not a member of agroup or the determination in step 1004 is that the reward program doesnot support reward point pooling, then the method proceeds to step 1016.Likewise, if the determination in 1010 is that the dependent accountstrategy does not allow the redemption of group reward points, then themethod proceeds to step 1016. In step 1016 the requesting account ispermitted to redeem points that are associated with the requestingaccount, but is not permitted to redeem group points.

[0179] As an alternative to reward point pooling, reward points can beshared between the accounts of a group via chasing. If chasing isimplemented, then reward points earned by an account remain at theaccount level. The points can be chased or collected from the accountlevel and used to satisfy a single redemption request.

[0180] Preferably, chasing is enabled or disabled by the reward program.If chasing is enabled by the reward program, then the accounts thatparticipate in the reward program can support chasing. If an accountsupports chasing, then the account permits another account to redeem itsearned reward points. If the account is a key account, then the optionto support chasing could be part of the predefined relationship betweenthe key account and the group. If the account is a dependent account,then the option to support chasing could be part of the dependentstrategy. The ability to chase reward points could expand beyond thegroup to accounts that are not members of the group.

[0181] If a cardholder makes a redemption request that exceeds thereward points associated with the cardholder's account, then adetermination is made as to whether the reward program supports chasing.If the reward program supports chasing, then the accounts that permitchasing in that reward program are identified. Points are chased fromthe identified accounts to satisfy the redemption request. The pointsare chased from the accounts based on a chasing option that specifieshow the points are chased from the identified account. The chasingoption could specify that the points are chased from the accounts on apro rata basis, on the basis of an account hierarchy, or on some otherbasis. Chasing could be performed by an operator pursuant toinstructions received by a cardholder. If chasing is performed by anoperator, then the accounts that support chasing are displayed and theoperator can select the accounts to chase. The operator can alsodetermine the number of points chased from each account.

[0182] Group Non-monetary Transactions

[0183] In addition to group monetary transactions, such as authorizing atransaction or allocating a payment, group non-monetary transactions arealso needed to support groups. A non-monetary transaction is atransaction that affects information for one or more accounts within thegroup, but does not affect the monetary information for the account. Forexample, a change in billing address is a non-monetary transaction,whereas the application of a payment is a monetary transaction. Otherexamples of non-monetary transactions include linking an account to anexisting group, delinking one or more accounts from a group, changingthe primary owner of a group, or changing the dependent strategy for adependent account.

[0184] Group non-monetary transactions can be used in both batch and online processing. Group non-monetary transactions update multipleaccounts within a group in response to a single input of the updatedinformation. To update the accounts in a group with updated groupinformation, the accounts within the group are identified. The accountsare identified using the group master data. As described in connectionwith FIG. 4B, the accounts in a group can be identified using the GroupMember file. Once the financial records are identified, then thefinancial records are updated with the new information.

[0185] Group non-monetary transactions also support the selectiveupdating of accounts within the group. For example, if only certainaccounts within the group are to receive the updated information, thenthe accounts in the group are identified and one or more of the accountsis selected and the selected account(s) is updated with the newinformation. In an on-line environment, an operator can select theaccounts that are to receive the updated information. In a batchenvironment, the updated information and the account numbers for theselected accounts can be submitted in batch.

What is claimed is:
 1. A method for pooling rewards earned in relationto a first account and a second account, the method comprising:determining that pooling can be applied to a first reward associatedwith the first account; determining that pooling can be applied to asecond reward associated with the second account; and combining thefirst and second rewards to form a reward pool.
 2. The method of claim1, wherein the first account and the second account are included in anaccount group, and wherein the reward pool is accessible to one or moremembers of the account group.
 3. The method of claim 2, wherein thefirst account is a dependent account, and wherein a dependent strategyassociated with the first account governs access to the reward pool. 4.The method of claim 2, wherein the first account is a dependent account,and wherein a dependent strategy associated with the first accountgoverns inclusion of the first reward into the reward pool.
 5. Themethod of claim 1, wherein the first and second accounts are members ofan account group, and wherein combining the first and second rewards toform a reward pool includes: accessing a first dependent strategyassociated with the first account, wherein the first dependent strategyallows for combining the first reward with the reward pool; andaccessing a second dependent strategy associated with the secondaccount, wherein the second dependent strategy allows for combining thesecond reward with the reward pool.
 6. The method of claim 2, whereinthe first and second accounts are dependent accounts, wherein a keyaccount is associated with the account group, and wherein the rewardpool is associated with the key account.
 7. The method of claim 5,wherein a third reward associated with the key account is combined withthe reward pool.
 8. The method of claim 1, wherein the first reward isselected from a group consisting of: point based rewards, and cash basedrewards.
 9. The method of claim 8, wherein the point based rewards areselected from a group consisting of: frequent flyer miles, discountpoints, insurance benefits, and merchandise.
 10. The method of claim 1,wherein the first reward and the second reward are of similar types. 11.The method of claim 1, the method further comprising: determining thatpooling cannot be applied to a third reward associated with a thirdaccount; and based at least in part on the determination, maintainingthe third reward in association with the third account.
 12. The methodof claim 11, wherein determining that pooling cannot be applied to athird reward associated with a third account includes: accessing adependent strategy associated with the third account, wherein thedependent strategy indicates that the third reward is not to be combinedwith the reward pool.
 13. The method of claim 11, wherein determiningthat pooling cannot be applied to a third reward associated with a thirdaccount includes: accessing a provider of the third reward, wherein theprovider of the third reward does not allow the third reward to bepooled with other rewards.
 14. The method of claim 13, wherein the thirdreward is associated with a first reward program, and wherein the thirdaccount is also associated with a second reward program, and wherein thesecond reward program does allow pooling.
 15. The method of claim 1,wherein the reward pool is associated with an account group, the methodfurther including: linking the second account to the account group; andadding the second reward to the reward pool.
 16. The method of claim 1,wherein the first account and the second account are linked in anaccount group, and wherein the reward pool is associated with theaccount group, the method further comprising: delinking the firstaccount from the account group, wherein the first reward remainsassociated with the reward pool.
 17. The method of claim 1, wherein thefirst account and the second account are linked in an account group, andwherein the reward pool is associated with the account group, the methodfurther comprising: delinking the first account from the account group,wherein the first reward is reassociated with the first account anddissociated with the reward pool.
 18. The method of claim 1, the methodfurther comprising: augmenting the first reward based upon activity inthe first account; and augmenting the second reward based upon activityin the second account.
 19. A method for redeeming rewards, the methodcomprising: combining a first reward associated with a first account anda second reward associated with a second account into a reward pool;receiving a redemption request from an owner of the first account,wherein the redemption request requires a reward greater than the firstreward; and accessing the reward pool to satisfy the redemption request.20. The method of claim 19, wherein the first account and the secondaccount are associated in an account group, and wherein the reward poolis associated directly with the account group, and not via an accountwithin the account group.
 21. The method of claim 19, wherein the firstaccount and the second account are associated in an account group,wherein the first account is a key account in the account group, andwherein the reward pool is associated with the first account.
 22. Themethod of claim 19, wherein the first account and the second account areassociated in an account group, and wherein the first account is adependent account within the account group, the method furthercomprising: accessing a dependent strategy associated with the firstaccount, wherein the dependent strategy governs access to the rewardpool via the first account.
 23. The method of claim 19, the methodfurther comprising: determining that the first account is associatedwith an account group; and determining that the reward pool isassociated with the account group.
 24. The method of claim 19, themethod further comprising: comparing the reward of the redemptionrequest with the total available reward of the reward pool.
 25. Themethod of claim 19, wherein the redemption request is associated with areward program, the method further comprising: determining that thereward program does not permit combining the first reward and the secondreward; and denying the redemption request where the redemption requestrequires a reward greater than the first reward.
 26. The method of claim19, wherein the redemption request is a first redemption request, themethod further comprising: subsequent to the first redemption request,receiving a second redemption request from an owner of the secondaccount; comparing a reward required to satisfy the second redemptionrequest with the reward pool, wherein the reward associated with thefirst redemption request was previously deducted from the reward pool;and satisfying the second redemption request where the reward poolincludes rewards greater than or equal to the reward required to satisfythe second redemption request.
 27. The method of claim 20, wherein theaccount group further comprises a third account, and wherein the rewardpool does not include a reward from the third account, the methodfurther comprising: receiving a redemption request associated with thethird account; and accessing the reward pool to satisfy the redemptionrequest.
 28. The method of claim 19, wherein the first reward is of acommon type to the second reward.
 29. The method of claim 23, whereinthe redemption request is automatically generated based at least in parton the amount of reward available in the reward pool.
 30. The method ofclaim 19, the method further comprising: distributing a rewardassociated with the redemption request, wherein distributing the rewardincludes distributing the reward to an owner of an account associatedwith the account group.
 31. A method for redeeming rewards, the methodcomprising: providing a first account, wherein the first account isassociated with a first party and a reward; receiving a request to add asecond party to the first account; adding the second party to the firstaccount, wherein the second party is associated with a pre-existingreward, and wherein the pre-existing reward is added to the reward; andreceiving a request to redeem the reward, wherein the request isinitiated by the second party.
 32. The method of claim 31, the methodfurther comprising: redeeming the reward based at least in part on therequest to redeem the reward.
 33. The method of claim 31, wherein thereward is a first reward, wherein the second party is associated with asecond account that is associated with a second reward, wherein therequest to redeem the reward includes a unified request to redeem atleast portions of the first and second rewards, the method furthercomprising: redeeming at least portions of the first and second rewardsbased at least on the unified request.
 34. A method for providingrewards associated with accounts, the method comprising: identifying afirst account associated with a first reward; identifying a secondaccount associated with a second reward; and associating the firstreward with the second reward in a reward pool.
 35. The method of claim34, the method further comprising: augmenting the reward pool onactivity in the first account.
 36. The method of claim 35, the methodfurther comprising: augmenting the reward pool based on activity in thesecond account.
 37. The method of claim 34, the method furthercomprising: determining that pooling can be applied to the first reward.38. The method of claim 34, wherein the first account and the secondaccount are included in an account group, and wherein the reward pool islinked to the account group.
 39. The method of claim 38, wherein adependent strategy at least partially governs the interaction of thefirst account with the account group, and wherein the dependent strategyindicates that the first reward can be combined into the account group.40. The method of claim 34, wherein the first reward is selected from agroup consisting of: a point based reward and a cash based reward. 41.The method of claim 34, wherein the first reward and the second rewardare of a common type.
 42. A method for making rewards accessible, themethod comprising: identifying a reward associated with a first owner;receiving a redemption request from a second owner; and accessing thereward and satisfying the redemption request from the second owner. 43.The method of claim 42, the method further comprising: augmenting thereward based on activity in the first account.
 44. The method of claim43, the method further comprising: augmenting the reward based onactivity in the second account.
 45. The method of claim 42, wherein thefirst account and the second account are included in an account group,and wherein the reward is linked to the account group.
 46. The method ofclaim 45, wherein a dependent strategy at least partially governs theinteraction of the first account with the account group, and wherein thedependent strategy indicates that the reward is to be linked to theaccount group.
 47. The method of claim 42, wherein the first account andthe second account are included in an account group, and wherein thereward remains linked to the first account.
 48. The method of claim 47,wherein the first account is a key account within the account group. 49.The method of claim 42, wherein the reward is selected from a groupconsisting of: frequent flyer miles, discount points, value applicableto certain purchases, insurance benefits, and merchandise.
 50. Anautomated method for redeeming rewards, the method comprising:monitoring activity associated with an account group, wherein theaccount group is associated with a reward pool; augmenting the rewardpool based at least in part on the monitored activity; determining thatthe augmented reward pool has achieved a defined level; andautomatically redeeming at least a portion of the reward pool.
 51. Themethod of claim 50, wherein the automatically redeemed portion isredeemed to an owner of a key account within the account group.
 52. Themethod of claim 50, wherein the automatically redeemed portion isredeemed to an owner of an account within the account group.